A site-to-site tunnel may be established for connecting a branch office network to a company's head office network. For example, the tunnel may be an Internet Protocol Security (IPsec) Virtual Private Network (VPN) tunnel. The VPN policies that are agreed upon by both ends at the time of tunnel establishment determine the encryption algorithm used for encrypting private data. The VPN gateway at either end encrypts and encapsulates outbound private data and sends it through the VPN tunnel to a peer VPN gateway over the Internet. On receipt of data through this tunnel, the peer VPN gateway removes the encapsulation and decrypts the payload and finally forwards the packet to the destination inside the private network. The VPN gateway at either end treats all the traffic the same and all the traffic gets encrypted at one end and decrypted at the other.
However, some of the private data sent through these VPN gateways may already be encrypted at the source and can only be decrypted at the final destination. For example, a secure shell (SSH) application may encrypt data before being passed to a local gateway to be again encrypted for transfer over the established tunnel. Such traffic gets double encrypted: once at the source (e.g., the SSH application) and next at the VPN gateway. Software implementation of encryption/decryption is usually processor intensive and can consume many processor cycles. Currently, there is no provision to prevent double encryption for already encrypted traffic at VPN gateways. Accordingly, processor cycles are being unnecessarily wasted to perform encryption/decryption at either end, resulting in lower network throughput.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.